IBIS Macromodel Task Group

Meeting date: 02 July 2019

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                            * Curtis Clark
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                              Radek Biernacki
                              Ming Yan
                              Stephen Slater
                              Maziar Farahmand
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                            * Mike LaBonte
SPISim:                     * Wei-hsing Huang
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Arpad to submit BIRD197.3 to the Open Forum per Bob's motion.
  - Done.  BIRD197.3 was introduced at the Open Forum meeting on June 28, 2019.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the June 18
meeting.  Randy moved to approve the minutes.  Walter seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD197.3 (DC_Offset and NRZ_Threshold):
Arpad noted that he had two issues with the newly submitted BIRD that might
need discussion.  The first was a comment from Randy captured in the previous
meeting's minutes:
"Randy noted that we are not really defining what to do.  He said it's
 convenient if the tool adds the DC_Offset back in for display of the waveform,
 but if the model has returned a waveform that already contains the offset this
 could be a problem.  By not defining things, we may end up with inconsistencies
 in the way various tools display the same output waveform."

The second issue was with this statement in the "Definition" of DC_Offset:
  "The mean value of the steady state high and low voltages of the channel at
   the Rx pad."
Arpad had sent an email to ATM about the interpretation of this statement, and
felt it might need further discussion.

Arpad opened discussion by asking Randy if he thought his concern from the
previous meeting had been adequately addressed.  Randy said he wasn't sure
there was something we should do about it.  He noted that it may be up to tools
to decide if they want to provide a way to shift the waveform.  He noted that
a tool probably can't do it automatically if it doesn't know what's coming out
of the Rx.  Arpad again pointed out the phrase "physical waveform" in
this sentence from the "Other Notes" section of the DC_Offset description:
  "The Rx AMI_GetWave output waveform is the physical waveform at the Rx latch.
   It can have a non-zero DC component, which can be time-varying."
Arpad asked if this sentence resolved any ambiguity, or if it needed to be
written more clearly.  Randy noted that this sentence had been taken to mean
that there would be a small DC offset in many cases.  Arpad suggested "physical
waveform" should mean something you could measure in the lab with a probe.
Walter said a voltage waveform had to be measured between two points, and the
logical thing to do is measure relative to the latch.  So, the waveform is
measured between the signal and the reference at the latch, and the DC
component would be quite small.  The latch has a reference voltage that will
determine whether the signal is considered high or low.  If we were going to
say the measurements are with respect to some local ground or rail, we would
have to specify that location in order to say, "physical waveform".

Arpad agreed with Walter, but asked what we would do if someone had a CMOS
architecture, and there was no reference voltage, and everything was measured
with respect to the ground or supply rails.  Walter said in that case the
model would return a non-zero NRZ_Threshold value.  Walter said that in practice
he didn't expect any model to add DC_Offset back in to the waveform it returned
or to return a non-zero NRZ_Threshold.  But if the model maker wants to return a
waveform with a 1V DC offset and specify an NRZ_Threshold value of 1V, we won't
prevent it.  We won't prevent the model from doing it, but models probably
won't do it anyway.  Walter suggested that all we need to do is add a sentence
explaining that NRZ_Threshold can be used in case a DC component is introduced
somewhere in the system.

Ambrish asked, regardless of the NRZ_Threshold value, if the EDA tool should
shift the waveform for display if the model does not do anything with the
DC_Offset.  Walter said no, the EDA tool can display the waveform relative to
the threshold (so DC offset would be zero - presumably the waveform as it was
returned by GetWave()).  Walter said the tool could also choose to add the
DC_Offset back in when displaying the waveform.

Ambrish asked how the tool would know whether the model had added in the DC
offset to the waveform already.  He noted that the tool could figure out if the
waveform weren't centered around zero, but this didn't seem to be an ideal
solution.  Walter noted that the value of NRZ_Threshold returned by the model
would be an indicator as to whether a non-zero DC offset had been added back
in (if the NRZ_Threshold were on the order of mV it probably hasn't, if the
NRZ_Threshold were .7V it probably has).

Walter said he certainly didn't want to force the model maker to add the
DC_Offset back in before returning the output waveform.  Ambrish agreed but said
we needed to add text to clarify the situation.  Walter proposed stating that
the model maker may choose to add DC_Offset to the output waveform, or they may
not.  Ambrish suggested the additional statement that if the DC_Offset is not
added back in then the output should nominally be centered about zero.  Ambrish
noted that "nominally" is already used on page 207 of the spec.

Arpad expressed concern that "NRZ_Threshold" might be abusing and overloading
the term "threshold" when compared to existing IBIS uses such as the PAM4
thresholds.  In a traditional differential case the threshold is a number
compared to the difference waveform, but here NRZ_Threshold is supposed to
return the VREFDQ reference level at the latch.  In our existing differential
flow the negative half of the signal would be the "threshold" according to this
new NRZ_Threshold definition.

Ambrish again noted that the BIRD had failed to address a relevant paragraph on
page 207 in IBIS 7.0, which describes the wave argument to AMI_GetWave().  This
statement on page 207 is directly affected by the BIRD:
  "The algorithmic model’s logic threshold may be non-zero, for example to model 
   the differential offset of a receiver. However, that offset will usually be
   small compared to the input or output differential voltage."
   
Ambrish noted that with this BIRD the offset might not be small, and this
section should be modified.  Walter proposed adding language to the section to
state that, "if the offset is important, the model can specify it using
NRZ_Threshold".  Ambrish agreed in principle.

Arpad asked who'd be willing to create another draft with the proposed language
changes.  Walter declined and said he did not think any of the changes were
necessary.  Ambrish took the AR to add a few clarifications.

Arpad noted that his second question could be discussed at the next meeting,
and we could move on to Randy's [C Comp Model] BIRD.

Complex C_comp modeling:
Randy reviewed some revised language with respect to K/T curve generation.  He
noted that he had replace references to K/T curve generation with the phrase
"C_comp compensation algorithm".

Arpad noted the sentence:
  "[C Comp Corner] values should represent the capacitance of the [C Comp Model]
   in Driving mode."
and asked if [C Comp Corner] should only be required for Output models and not
required for Input models.  Randy noted that it wouldn't be much of a burden to
the model maker to take a required C_comp value and put the same value into the
three [C Comp Corner] entries, even for an Input.  This would avoid cluttering
up the spec with additional conditionals.  Bob agreed and noted that if-this-
then-that rules for required parameters could get confusing, and he noted that
IBIS had tried to avoid this in the past.  After some discussion, the group
agreed that it was not an undue burden on the model maker to provide
[C Comp Corner] any time [C Comp Model] is used.  Walter noted that a model
maker sophisticated enough to be using [C Comp Model] would be able to add
[C Comp Corner].  Randy proposed adding a sentence explaining that [C Comp
Corner] values may be ignored by EDA tools for a [C Comp Model] in Non-Driving
mode.

Randy then noted that he had removed this sentence:
  "The Param values shall all be numerical or all string values (or NA)."
from the Corner format description.  He noted that a previous sentence in the
section had already made this clear.

Randy noted that he had changed the language describing the rules of precedence,
as discussed in the previous meeting.

Mike L. asked Randy to review the BIRD to make sure it did not introduce any new
parameters whose values were names as opposed to numbers.  He noted that in IBIS
7.0 several new keywords contained names, and we had forgotten to specify the
limits on their lengths.  Randy noted that he would check, but he didn't think
that was an issue with this BIRD.

- Randy: Motion to adjourn.
- Bob: Second.
- Arpad: Thank you all for joining.

AR: Ambrish to produce a draft of BIRD197.4 incorporating NRZ_Threshold and
    DC_Offset clarifications.
    
AR: Randy to create a new [C Comp Model] BIRD draft incorporating the changes
    discussed in the meeting.

-------------
Next meeting: 09 July 2019 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
